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(57) Abstract: The invention concerns an application programmer no longer responsible for managing access rights, the application 
code being independent of the protection in the chip card. The capabiD ty-based access control consists, when an application (Aa). 
for example in a docking station, is given access to an object (Obi) pertaining to the other application (Ab) in a chip card (CP), in 
creating two capabilities (Fa(Obl), Fb(Obl)) respectively in the appUcaUons, as objects, to protect all subsequent accesses to the 
object by filtering them through the two capabilities. On accessing (El) an object (Obi) pertaining to an application (Ab), if a second 
object (Ob2) pertaining to the other application ( Ab) is passed on to the latter, two other capabUiues (Fa(Ob2. Fb(0b2)) are added 
(E2) in the applications to protect access to the second objea. 

[Suite sur la page suivante] 


wo ni/42887 A2 lillilllilllMiiMBilMiMI 


MC, NL, FT, SE TR), brevet OAPl (BF, BJ, CF. CG. CI. En ce qui conceme les codes a deux iettres et autres abrevia- 
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abreviations" figurant au debut de chaque numero ordinaire de 

Publiee: la Gazette du PCT 

— Sans rapport de recherche Internationale, sera republiee 
dh reception de ce rapport. 


(57) Abrtgi: Un programmeur applications ne se soucie plus de la gestion des droits d'accfts, le code des applications ^tant 
ind^pendant de la protection dans une carte ^ puce. Le contdle d^acc^s par capacit€s comprend, lorsqu'a une appUcation (Aa), par 
exeraple dans une station d^accueil de carte, est donn^ un acc^ ^ un objet (Obi) appartenant ^ Tautre application (Ab) dans une carte 
^ puce (CP), la creation de deux capacit^s (Fa(Obl). Fb(Obl)) respectivement dans les applications, en tani qu'objets, pour prot^ger 
tous les accfes ult^rieurs a Tobjet en les filtranl au travers des deux capacity. Lors de Tacc^s (El) a un objet (Obi) appartenant ^ 
une application (Ab), si un deuxiftme objet (Ob2) appartenant ^ I'auire application (Ab) est passd a celle-ci, deux autres capacitds 
(Fa(0b2), Fb(0b2)) sent ajout&s (E2) dans les applications pour protdgcr I'acc^s au deuxifeme objet. 
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Controle d'acces par capacltSs pour des applications 
notaxnment cooperantes dans une carte k puce 

L' invention concerne les cartes a puce, dites 
egalement cartes a microcontr61eur ou cartes a 
circuit ±nt€gT6, et plus gen^ralement des moyens de 
traitement de donnees ouverts programmables pouvant 
§tre charges' d* applications ecrites dans des langage 
de programmation #volues. 

Une carte a puce ouverte, telle que presentee 
par exetnple dans le document WO 98/19237, gere 
plusieurs applications, par exemple un compte client 
pour un magasin, un compte bancaire ou un porte- 
monnaie ^lectronique. Certaines applications chargees 
dans la carte cooperent parfois par exemple pour 
payer un achat du magasin^ et/ou coopdrent Egalement 
avec des applications s* executant hors de la carte. 

La cooperation des applications impose 
1 'gtablissement de regies de droit d'accds, les 
applications ne se faisant pas forc#ment confiance. 
Par exemple, le compte client gere par le magasin ne 
doit pas s'approprier de donnees gerees par le porte- 
monnaie ^lectronique. 

Dans un environnement informatique, la gestion 
du contr61e d'acces consiste S associer des droits 
d'acces a des objets gergs dans 1 ' environnement pour 
chaque usager, et S verifier que ces droits d'accis 
sont respectSs. 

La gestion du controle d'acces est schematisee a 
la figure 1 par la gestion d'une matrice d'acces MA. 
Les lignes de la matrice MA correspondent aux droits 
de J objets 01 S OJ et les colonnes de cette matrice 
correspondent aux droits de I usagers Ul S UI . Une 
case de la matrice a 1 ' intersection d'une ligne et 
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d'une colonne donne des droits d'acces Dij d'un 
usager Ui sur un objet 0 j , avec l=i=Ietl=j= 
J, par exemple un droit de lire, d»6crire ou 
d*executer un fichier. 
5 En pratique, la mat rice MA est partiellement 

vide, des usagers n'ayant souvent aucun droit sur de 
nombreux objets, et prfisente I'une des deux 
configurations consistant en \an regroupement des 
droits d'accds par ligne et en un regroupement des 

10 droits d'accds par colonne. 

Le regroupement par ligne revient k associer h 
chaque objet O j , une liste d'acces indiquant les 
droits d'acces Dlj a DIj sur 1* objet respectivement 
pour les usagers Ul a UI. Dans une gestion par listes 

15 d'accds respectivement associ§es a des objets, seul 
le propriStaire d'un objet Oj modi fie la liste 
d'acces Dlj k DIj associ^e k 1' objet ; une telle 
modification se fait explicitement en appelant une 
operation sur 1' objet demandant la modification de sa 

20 liste d'accSs. Les sch^mas de protection t base de 
listes d'accds sont alors qualifies de statiques, la 
modification des droits d'acces etant complexe et les 
usagers ayant tendance ^ surdimensionner les droits 
d'accds de leurs objets. Ceci va a I'encontre du 

25 principe du moindre privilege (en anglais : need to 
know principle) selon lequel des droits d'accds ne 
sont accordSs qu'au fur et ^ mesure des besoins. 

Le regroupement par colonne associe a chaque 
usager Ui une liste de capacit^s indiquant les droits 

30 d'acces Dil a DiJ de 1' usager respectivement pour les 
objets sur lesquels l»usager possede un droit. Chaque 
element (Oj , Dij) de la liste est appele une 
capacite. Une capacity est un descripteur contenant 
1 'identification d'un objet Oj ainsi qu'une 

35 definition de droits d'acces Dij sur cet objet. Dans 
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une gestion par capacltSs, un usager possede une 
liste de capacitSs, une capacity pouvant §tre 
comparee k un jeton donnant le droit de faire une 
operation sur I'objet. Une capacite identifie un 
5 objet, mais inclut en plus une definition des droits 
d'acces sur I'objet. Une capacity peut alors Stre 
utilis^e comme un identif icateur d'objet qu'une 
application peut passer en paramgtre k une autre 
application, en suivant un mode de programmation 
10 classique, avec la limitation que cet identif icateur 
n'autorise pas toutes les operations sur I'objet 
d^signe . 

II en decoule que la modification des droits 
d'accds est plus naturelle avec des capacit^s : 

15 accorder a une application ou un usager des droits 
d'acces a un objet revient a lui passer en parametre 
d'une operation I'identite de 1' objet sous la forme 
d'une capacite. 

Les capacites apportent une plus grande 

20 dynamique dans la gestion du contrdle d'acces, les 
droits d'acces pouvant etre ais^ment echanges entre 
les usagers de 1 'environnement . Cependant, lorsqu'un 
usager ou une application doit passer en paramdtre 
une capacity sur un objet, 1 'usager ou 1 'application 

25 doit auparavant decider des droits a transferer avec 
la capacity. Une operation permet en general de 
rSduire les droits associSs k la capacity si 
necessaire, avant de la passer en parametre. 

Dans la technique ant^rieure, sont connues des 

30 realisations mat^rielles et des realisations 
logicielles des capacites comparables a des jetons. 
Les premidres realisations materiel les reposaient sur 
des machines specialisees dans les annees 70. Le 
mecanisme d'adressage de ces machines implantait 

35 directement la notion de capacite : un registre 
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d'adresse servant a adresser un objet contenait 
6galement les droits d»accds H !• objet (le registre 
contenant le jeton) . Les valeurs de ces registres 
pouvaient etre echang^es entre les usagers, mais ne 
5 pouvaient pas etre forgoes, le materiel ne le 
permettant pas. Les realisations logicielles, plus 
recentes dans les annees 80, reposaient sur le 
chiffrement pour la protection des capacitgs, Une 
capacite 6tait signee et ne pouvait etre cre6e que 
10 par le propri^taire de 1* objet. 

Ainsi, le document US 5781633 illustre une 
technique anterieure permettant un filtrage, au moyen 
de capacit§s, d'echanges de references d'objets entre 
differents processus. Des precedes cryptographiques 
15 sont utilises pour garantir principalement 
I'int^grite des references ^chang^es. La cooperation 
entre processus est realisee par la transmission 
d'une vue r^duite d'un objet d'un processus, k un 
second processus. Le filtre ainsi cr66 est implante 
20 au sein du processus demandeur d'accSs. Dans un 
contexte de type « processus mutuellement m^fiants », 
le procSde divulgug par le document est inop6rant. En 
effet le processus demandeur d'accds peut modifier k 
sa guise le filtre qui lui a 6t€ transmis et acceder 
25 ainsi a des mSthodes qui lui sont pourtant 
interdites. 

L' invention a trait plus particulierement k un 
m^canisme de contr61e d'accds base sur un schema de 

30 protection par capacites pour gSrer la cooperation 
entre des applications dans le contexte d'une carte k 
puce. En effet, le contexte de la carte S puce se 
caracterise par des cooperations entre des 
applications non prevues a I'avance. II est done 

35 difficile de satisfaire un schema de protection comme 
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les listes d'accds ou les droits d'acces sont le plus 
souvent pr6-6tablis. La dynamique du schema a base de 
capacites est un reel besoin. 

Dans les solutions actuelles dans le contexte de 
5 la carte a puce, un programmeur doit g6rer des 
capacites "a la main" dans le code de 1 ' application, 
ce qui conduit a une complexity de programmation des 
applications prot^g^es. 

L* invention implante un modele a capacity dans 
10 le contexte de la carte a puce pour poursuivxe deux 
objectifs : 

- Pr^seorver la simplicite de programmation du 
langage JAVA dans le contexte de la JAVA Card. Pour 
ce faire, 1' invention vise a rendre le code des 

15 applications ind^pendant de la protection. La 
specification de la politique de protection, c'est-i- 
dire de la gestion des capacites, est sSpar^e du code 
des applications. 

Permettre la cooperation entre des 

20 applications dans la carte, mais ggalement entre des 
applications dans la carte et des applications hors 
de la carte. Ceci necessite de considerer le systdme 
d' exploitation dans la carte comme un milieu sScurise 
et I'exterieur de la carte comme un milieu hostile. 

25 L'atteinte de ces deux objectifs par 1» invention 

apporte une grande simplicity de programmation du 
contr61e d'acces,.ce qui rSduit Sgalement le coflt de 
dSveloppement et de maintenance du code, ainsi que 
les risques d'erreur de programmation de la 

30 protection. 

Le premier object if conduit a separer le 
developpement de 1 ' application et la gestion des 
droits d'acces, simplifiant ainsi la complexity. Le 
programmeur d ' applications programme des applications 

35 sans se soucier de la gestion des droits d'accSs. 
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Celle-ci est specifiee s§par6ment dans un formalisme 
simple et trds intuitif. 

Pour le deuxidme objectif, 1' invention off re un 
modele de gestion des droits d'accds uni forme alors 
5 que les contraintes sous- jacentes sont trds 
diffSrentes lorsque I'on se trouve dans la carte ou 
hors de la carte. 

Les deux objectifs repondent Sl la m§me 
motivation consistant ^ masquer les complexit^s 
10 inh^rentes a la protection et a la carte, et ^ 
simplifier la programmation d' applications 
cooperantes protegees. 

Pour atteindre ces objectifs, 1 ' invention fournit 
15 un procedS de gSnSration d' applications caractSris^ 
en ce qu'il coraprend : 

- une 6tape de developper une application 
comprenant un objet ou plusieurs objets, sans 
restriction d'accis ; 

20 - une 6tape de dSfinir des rSgles de droits 

d'acces a 1' objet ou aux objets, compris au sein de 
1' application, depuis une seconde application ou 
depuis plusieurs autres applications ; 

- une etape de transformer 1 ' application 
25 comprenant le ou les objets par ajout a ladite 

application, de moyens de filtrage des accSs audit 
objet ou auxdits objets pour mettre en cBuvre un 
procSdg de contrdle d'acces assurant la cooperation 
des applications; 
30 - une etape d'implanter 1 ' application 

transform^e au sein d'un moyen de traitement de 
donnees . 

Selon une premiere realisation, le moyen de 
traitement de donnees est inclus dans une carte a 
35 puce. 
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Selon une seconde realisation, lie moyen de 
traitement de donn^es est inclus dans une station 
d'accueil de la carte a puce. 

En outre, selon 1' invention, le proc6d§ de contrdle 
5 d'acces entre deux applications coopirant chacxine au moyen 
de capacit§s sur des objets appartenant ct 1* autre 
application, les applications coop§rant i travers au moins 
vn systdme d* exploitation, est caract6ris§ par I'^tape 
suivante : 

10 lorsqu'a I'une des applications, dite 

application demandeur d'acces, est donne un accSs k 
un objet appartenant a 1' autre application, dite 
application fournisseur d'acces ; 

cr6er deux capacitSs respect ivement dans 
15 lesdites applications demandeur et fournisseur 
d'acces, en tant qu' objets ; 

la capacite creee dans 1 ' application fournisseur 
d'acces pour limiter I'acces audit objet et ; 

la capacity cr^ee dans 1 ' application demandeur 
20 d'acces pour associer 1 ' application demandeur d'accds 
a la capacity creee dans 1' application fournisseur 
d'acces . 

Selon un autre aspect de 1' invention, lors de 
I'acces a un objet appartenant a I'une des 

25 applications, si un deuxieme objet appartenant ^ 
I'une des applications est passe a cette application, 
le precede comprend I'etape d'aj outer deux autres 
capacites respectivement dans les applications pour 
protSger I'accds au deuxidme objet. 

30 En pratique, la capacity d'accds au deuxidme 

objet appartenant k I'une des applications est pass6e 
en paramdtre ou en r6sultat & 1* autre application. 

Selon une premiere realisation, les applications 
peuvent §tre implant^es dans un moyen traitement de 

35 donn^es commun, par exemple dans une carte ^ puce ou 
un terminal. Dans le cas d'une carte S puce, les 
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verifications du code chargS dans la carte a puce 
pertnettent d» assurer qu'une capacity ne peut §tre 
cr66e par un progranutieur pirate. 

Selon une deuxidme realisation, les applications 
5 sont iTT5)lantees dans deux moyens de traitement de 
donnSes distants §changeant des messages d»acc§s ^ 
des objets distants. L'Stape d'ajouter deux autres 
capacit6s peut comprendre alors de preference le 
stockage d'un mot secret dans les deux autres 

10 capacitfis, pass6 a celles-ci par les deux capacit^s 
precedemment creees a I'etape de creer, afin de 
valider I'acces au deuxieme objet. 

Les moyens de traitement de donn^es peuvent etre 
Indus respect ivement dans une carte h puce et une 

15 station d'accueil de la carte ^ puce, ou dans deux 
cartes a puce distinctes, ou dans deux controleurs 
d'une carte a puce ou d'un terminal. 

D' autres caracteristiques et avantages de la 
20 pr^sente invention apparaltront plus clairement IL la 
lecture de la description suivante de plusieurs 
realisations preferSes de 1' invention en reference 
aux dessins annexes correspondants dans lesquels : 

- la figure 1 montre une matrice de droits 
25 d'accds dejS commentee ; 

- la figure 2 est un bloc-diagramme montrant des 
interfaces entre une application banque et une 
application client ; 

- la figure 3 est un bloc-diagramme montrant des 
30 interfaces de deux applications cooperantes selon 

1* invention ; 

- la figure 4 est un bloc-diagramme montrant 
1 'implantation d'objets filtres entre deux 
applications cooperantes S une etape initiale de 

35 precede selon 1' invention ; 
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- la figure 5 est un bloc-diagr amine montrant 
I'adjonction de deux filtres lors de I'appel par une 
application de la m€thode sur un premier objet dans 
une autre application, selon une premiere realisation 

5 du procedS de 1 ' invention ; et 

- la figure 6 est un bloc-diagramme analogue cl 
la figure 5, montrant I'adjonction de deux filtres 
lors de I'appel par une application dans une station 
d'appel de la m^thode sur un premier objet dans une 

10 autre application dans une carte a puce, selon une 
deuxieme realisation de 1* invention. 

Le concept general sous-jacent a 1' invention est 
la gestion de capacites, c'est-a-dire la gestion de 
15 droits d'acces ^l^mentaires, de fagon separee d'une 
application, 

Lorsque deux applications cooperent, cette 
cooperation suit un protocole de cooperation pr6- 
gtabli- Ce protocole de cooperation prend 

20 g6n6ralement la forme d'une interface commune 
permettant aux applications de s'appeler. Plus 
prScisement, dans le contexte de la JAVA Card, chaque 
application qui desire appeler une autre application 
le fait en utilisant une interface JAVA qui est celle 

25 qu'est sensSe foumir 1 ' application appelSe. 

En reference k I'exemple illustre S la figure 2, 
une banque BA, c*est-li-dire une application banque 
dans un serveur, gSre des comptes pour des clients. 
Lorsqu'un client CL se connecte ^ la banque k travers 

30 un objet Guichet OG, la banque lui retourne une 
reference Ref sur son objet Compte en banque OC pour 
qu'il puisse lire I'Stat de son compte. Chacune des 
applications banque et client connait les interfaces 
de cooperation IG et IC qui sont eel les des objets 

35 Guichet et Compte. L' interface de 1' objet Guichet IG 
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permet au client de se connecter a la banque en 
donnant son nom et un code d*acces, tel qu'un code 
d' identity personnel PIN (Personal Identity Number), 
et de lui retourner la reference Ref a I'objet Compte 
OC . L • interface de 1 ' obj et Compte IC f oumit deux 
mSthodes respect ivement pour lire et ecrire le solde 
du compte en banque, la syntaxe utilis6e etant celle 
du langage JAVA. 

Les besoins en termes de protection dans cet 
exemple sont presentes ci-apres. La banque possede 
tous les droits sur ses propres objets. Mais il est 
impensable que la banque accorde tous les droits k 
ses clients. Un client peut lire le solde de son 
compte en banque, mais ne doit pas §tre autorisg k 
ecrire arbitrairement le solde de son compte. C'est 
pourquoi, dans un schema de protection par capacitSs, 
la banque retoume en rgsultat de 1' operation de 
connexion une capacite correspondant a la rgfSrence 
sur I'objet Compte, mais avec des droits qui ne 
permettent que I'appel de 1« operation de lecture de 
compte. La banque qui possede tous les droits sur ses 
propres objets, y compris I'objet Compte, cr6e une 
capacity n'autorisant que la lecture sur cet objet et 
retoume cette capacity a son client. 

Etant donn4 que le premier object if vis6 par 
1« invention est de separer la definition de la 
politique de protection et le code de 1 'application, 
1» invention vise plus particuliSrement k fournir des 
r§gles d'Schange de capacity entre les applications 
au niveau des interfaces utilis6es pour coopSrer. 

Dans 1" exemple montrg k la figure 2, la 
fourniture du contr61e d'accds par programmation est 
situ6e au niveau de 1' interface de I'objet Guichet OG 
de la banque BA. Selon un premier aspect de 
1' invention, cet outil de programmation specif ie dans 
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les interfaces utilisSes la capacity qu'il faut 
transferer lors d'une transmission de parametre entre 
des applications. On obtient une interface "prot4g§e" 
appelee vue (view en anglais) qui prend la forme 
5 suivante en langage JAVA, le mot "String" dgsignant 
un objet de chaine de caract^res : 

view guichet { 

Oarptejolient connexion (String nan. String pin-code) ; 

10 ; 

view Comptejclient { 
Solde lire () ; 
NOT void ecrire (Solde s) ; 

} 

15 

La specification de ces deux vues indique que la 
banque BA ne laisse sortir que des capacitSs 
permettant de lire le solde des comptes. Le code de 
1 'application banque et de 1 ' application client reste 

20 ainsi totalement indSpendant de la protection. 

De fagon plus generale, l*outil de programmation 
permet a chac\ine des applications, 1 • application 
banque et 1 ' application client selon I'exemple 
pr6c§dent, de d^finir ses propres regies de 

25 protection. Lorsqu'une application AA possdde une 
capacity vers un objet OB d'une application AB comme 
montr6 a la figure 3, la capacity inclut les regies 
de protection dgfinies par 1 ' application AA et 
regroup§es dans une interface protegee "vue" lA et 

30 les regies de protection dSfinies par 1 ' application 
AB et regroupees dans une interface protegee "vue" 
IB. La vue IB a deux roles : limiter les methodes que 
1» application AA peut appeler sur 1 'objet OB et 
associer la vue choisie par 1 'application AB aux 

35 capacites entrantes dans et sortantes de 
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1 •application AB lorsque I'objet OB est appelS. La 
vue lA ne remplit que le deuxidme r61e pour les 
capacites entrantes dans et sortcUites de 
1 'application AA. 
5 Ainsi, pour chaque capacite echangfie en 

parametre de I'appel depuis 1 • application AA vers 
1 » application AB, ou depuis 1 'application AB vers 
1 'application AA, la vue lA associe une vue IA» S 
cette capacite et la vue IB associe une vue IB* 4 
10 cette capacite. 

Un autre aspect de 1' invention est 1 ' integration 
de I'outil de prograramation dans le contexte de la 
carte a puce. Dans le contexte d'une carte k puce 

15 ouverte, des applications sont chargees dans la 
carte. Ces applications, dites applications internes, 
interagissent entre elles, raais egalement avec des 
applications, dites applications extemes, ex6cut6es 
dans une station d'accueil, telle qu'un terminal 

2 0 bancaire, un point de vente ou un terminal 
radiotSl^phonique mobile, dans laquelle la carte est 
insSrSe. Ceci implicjue que des capacites sont 
gchangees entre des applications internes et des 
application externes. L'outil de programmation 

25 associe a 1 ' invention est mis en place en considerant 
les parties suivantes de ce contexte liees a la carte 
et a la station d'accueil : 

- La carte k puce JAVA Card est un milieu 
prot#g§ dans le sens oQ le code JAVA charge dans la 

30 carte a puce est v6rifi6 avant son chargement 
effectif. Cette verification vise a assurer que le 
code a charger possdde bien certaines propriStSs du 
code JAVA, principalement li^es h la security. Le 
langage JAVA ne permet pas de manipuler directement 

35 des adresses et done d*6craser arbitrairement de la 
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tnSmoire, ce qui assure un certain degre de s6curit6 
lorsque different s programmes sont h§berg§s dans la 
meme machine virtuelle JAVA. L' implantation du schema 
de protection de 1' invention tient compte de ce 
5 contexte interne a la carte pour 1 ' implantation des 
capacit^s dans la carte. 

- La station d»accueil dans laquelle la carte 
est inseree n'est pas forciment un milieu securisg. 
En effet, la carte peut etre ins6r§e dans n'importe 
10 quelle station d'accueil, et la station d'accueil 
peut tres bien envoyer des donnees fabriquees pour 
tromper la carte. Lorsqu'elles sont propagees hors de 
la carte, les capacites sont selon 1 ' invention 
protegees par des secrets qui permettent de verifier 
15 la validite des capacites utilisees par des 
applications externes a la carte. 

L' invention porte ainsi sur un outil de 
programmation pour programmer la gestion des droits 
d'accSs entre des applications cooperantes 
20 s' executant dans la carte k puce ou dans la station 
d'accueil. La definition des regies de gestion des 
droits d'accds est separSe du code des applications, 
ce qui confdre une plus grande clartg. L ' integration 
dans le contexte de la carte a puce JAVA Card 
25 nScessite de g^rer diffgremment les capacites dans la 
carte a puce et k I'exterieur de celle-ci. 

L» outil de programmation associg k 1' invention 
sp6cifie les rdgles de protection d'une application 
30 sSpar^ment du code de 1 'application. 

II est suppose qu'une premidre application Aa 
Scrite en langage JAVA coopere avec une deuxidme 
application Ab egalement gcrite en langage JAVA k 
travers une interface de cooperation lab implantee 
35 dans un unique moyen de traitement de donnSes, par 
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exemple une carte k puce avec un systeme 
d' exploitation specif ique et la machine virtuelle 
JAVA : 

interface lab { 

void methl (II pi) ; 
12 meth2 0; 
void methS (); 

} 

L' interface lab contient les definitions de 
trois methodes tnethl, Tneth2 et meth3. La m^thode 
methl prend en parametre pi une reference a un objet 
de type interface II et ne retourne aucun resultat. 
La mSthode meth2 ne prend aucun parametre et retourne 
un r^sultat de type interface 12. La m^thode meth3 ne 
prend aucun parametre et ne retourne aucun resultat. 

Chaque application specific alors des interfaces 
de protection appelees vues, par exemple les vues 
suivantes Iab_V, I1_V1 et I2_V2 : 

view Iab_y{ 

void methl (II J/1 pi) ; 
I2_V2 meth2 ()/ 
NOT void meth3 (); 

} 

Lorsque 1 • application Aa possede une capacity 
sur un objet appartenant ^ 1 'application Ab, les 
applications Aa et Ab ont la possibility de specifier 
la protection S associer a cette capacity en 
associant une vue a cette capacity . 

La vue Iab_V indique que aeules les m€thodes 
methl et meth2 sont autoris^es. Elle indique aussi 
que si la methode methl est appelie, alors 
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1 'application, qui peut gtre une application 
appelante ou une application appelfie, se protdge en 
associant d la capacity passSe en paramgtre la vue 
I1_V1. Enfin, elle indique que si la mithode meth2 
est appelee, alors 1 'application se protdge en 
associant a la capacity pass^e en r^sultat la vue 
I2_V2 . 

Lorsque 1 ' application Aa possdde une capacity 
vers un objet de 1 'application Ab, la vue que 
1 'application Aa associe a cette capacity permet £l 
1' application Aa de controler les capacit^s qui 
entrent dans et sortent de celle-ci, c'est-a-dire 
d'associer a ces capacit^s une vue. RSciproquement , 
la vue que 1 ' application Ab associe a cette capacity 
permet a 1 'application Ab de contr61er les capacitSs 
qui entrent dans et sortent de celle-ci, mais aussi 
de limiter les mSthodes qui peuvent etre appelees sur 
1' objet de 1 'application Ab. 

En gSnfiral, la premiere exportation d'une 
capacity d'accds depuis 1 'application Ab vers 1 'autre 
application Aa et la premiere importation de cette 
capacity par 1' autre application Aa, passent par un 
serveur de nom. L' application Ab exporte la capacity 
d'acces en 1' associant a un nom symbolique, tel 
qu'une chaine de caracteres, et 1 ' application Aa 
importe la capacite d'acces exportee en interrogeant 
le serveur de nom avec le nom symbol ique. 
L' application Ab exporte la capacity en spScifiant 
explicitement la vue que 1 'application Ab y associe. 
L' application Aa importe la capacity exportee en 
specif iant explicitement la vue que 1 'application Aa 
y associe. Pour 1 'application Aa comme pour 
1 'application Ab, la vue specif i6e indique pour tous 
les ^changes de capacity en parametre decoulant de ce 
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premier ^change, les vues qui seront associSes a ces 
capacites passees en paramStre. 

II en resulte que, except^ ce premier echange de 
message de capacity d'acces, la politique de 
5 protection de chaque application selon 1' invention, 
c'est-a-dire la maniere d'Schanger les capacites, est 
specif iSe au niveau des interfaces et n'est pas noyee 
dans le code de 1 • application. 

10 implantation de la politique de protection 

selon 1 'invention repose sur la notion d'objets 
filtres, "illustrant" des objets capacites 
(signifiant aptitudes ou facultes, ou en anglais 
"capabilities"), qui sont insures entre les 

15 applications Aa et Ab. Pour chaque vue d€finie par 
une application, une classe filtre est gener^e et une 
instance de cette classe est ins^ree & 1 'execution 
dans la chaine d'accds a \in objet dont une capacite 
est exportee. Comme montrS k la figure 4, si k une 

20 6tape initiale EO un acces a un objet Ob appartenant 
a 1 'application Ab est donn6 a 1 ' application Aa, la 
vue de 1 'application Aa pour la capacity de cet acces 
est implantSe par un filtre Fa et la vue de 
1 'application Ab pour cette capacity est implantSe 

25 par un filtre Fb. 

Une classe filtre dSfinit toutes les m§thodes 
dSclarSes dans la vue que le filtre implante. Son 
r61e est de retransmettre I'appel de m^thode vers son 
successeur dans la chaine d' acces a 1 'objet. Selon 

30 I'exemple montre a la figure 4, le filtre Fa 
retransmet I'appel vers le filtre Fb et le filtre Fb 
vers 1' objet Ob. 

Par contre, une classe filtre implante la 
politique de protection difinie par la vue a partir 

35 de laquelle elle est g€n€r€e : le filtre Fb ne laisse 
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passer que les m^thodes autoris€es par la vue de 
1 'application Ab ; et les filtres Fa et Fb implantent 
aussi 1 'association des vues aux capacit^s passees en 
parametre. Selon I'exeraple de vues ci-dessus, la vue 
5 Iab_V indique 1 ' association de la vue I1_V1 au 
parametre pi de la methode methl. L' association de la 
vue i la capacite est implantee en insurant dans la 
chaine d'accds a I'objet pass6 en parametre un objet 
filtre correspondant a la vue. 
10 En reference a la figure 5, pour deux 

applications Aa et Ab implantees dans une carte a 
puce CP, 1 'application Aa possede a I'etape initiale 
EO une capacite vers 1 'objet Ob de 1 ' application Ab, 
et comma dans la figure 4, les acces ult^rieurs a 
15 1 'objet Ob sont proteges par le filtre Fa (Ob) de 
1 'application Aa et par le filtre Fb(Ob) de 
1 'application Ab. A une premiere 6tape El, lors de 
I'appel par 1 ' application Aa de la mSthode methl sur 
1 'objet Ob appartenant a 1 'application Ab, c'est-S- 
20 dire lors de I'accds S 1 'objet Ob, une capacity sur 
un objet Oa appartenant a 1 'application Aa est pass€e 
en parametre a 1' autre application Ab. Pour mettre en 
oeuvre la protection specif iSe par 1 • application Aa 
dans sa vue k une deuxieme Stape E2, le filtre Fa (Ob) 
25 ajoute le filtre Fa(Oa) et le passe en paramStre de 
la mSthode methl a la place de la r#f6rence directe ^ 
1 'objet Oa. De meme, pour mettre en oeuvre la 
protection spScifige par 1 'application Ab dans sa 
vue, le filtre Fb(Ob) ajoute le filtre Fb(Oa) et le 
30 passe en paramdtre de la m^thode methl a la place du 
parametre regu. 

Les objets filtres Fa(Ob) et Fb(Ob), lorsqu'ils 
sont appeles, sont done charges d' installer des 
objets filtres Fa(Oa) et Fb(Oa) pour les rSfgrences 
35 passSes en paramdtre ,- en d'autres termes, deux 
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capacites illustrees par les filtres Fa(Oa) et Fb(Oa) 
protSgeant I'acces d I'objet Oa sont ajoutSes 
respectivement dans les applications Aa et Ab. 

5 II est indique ci-aprds un exemple de classe 

filtre gSneree F_Iab_V pour la vue Iab_V donnie 
auparavant, rappelee ci-apres : 

view JaJb_V { 
10 void methl (I1_V1 pi) ; 

I2_y2 meth2 () ; 
NOT void meth3 () ; 

} 

15 Pour les vues I1_V1 et I2_V2 sont cr^^es 

respectivement des classes filtres F_I1_V1 et 
F_I2__V2. II est suppose que les deux applications Aa 
et Ab qui cooper ent se trouvent dans le meme 
environnement JAVA et les lignes suivantes sont 

20 encore Sorites en code JAVA, dans lesquelles le mot- 
cl6 public signifie que la tnethode declaree suivante 
est accessible a toutes les classes, le inot-cl6 void 
signifie que la m§thode dSclarSe suivante une fois 
ex^cutSe ne retoume aucun r^sultat, et le mot-cl§ 

25 new d^signe un opgrateur de creation de classe : 

public class F_Iab_V implements lab { 
lab obj; 

30 public F_Iab_V (lab o) { 

obj = o; 

} 


35 


public void methl (I1_V1 pi) { 

obj. methl (new FJL1_V1 (pi)) ; 
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public I2_V2 meth2 () { 

return (new F_I2_V2 (obj .ineth2 () ) ) ; 

} 


public void meth3 () { 

// propager une exception 

} 

10 ; 


La variable obj est une reference a I'entite 
suivante dans le chemin d'acces a I'objet, le 
deiixieme filtre ou I'objet reel. Elle est utilisSe 

15 pour retransmettre I'appel s'il est autorise. 

• La mSthode F_Iab_V est la methode constructeur 
de la classe filtre. Elle initialise la variable obj. 
Lorsque 1 * application Aa importe une capacity du 
serveur de noms et veut lui associer la vue Iab_V, 

20 elle appelle la m§thode constructeur en lui passant 
en paratndtre la reference JAVA regue. 

La methode methl retransmet un appel qui est 
done autoris^, mais elle doit associer S la capacity 
pass6e en paramdtre pi la vue I1_V1. La methode methl 

25 cr6e par I'opSrateur new un filtre F_I1_V1 k partir 
du paramdtre regu, puis retransmet 1* appel en passant 
en parametre pi la r§f6rence au filtre cree. 

La mgthode meth2 retransmet 1' appel et elle 
regoit en retour une capacity. Elle doit y associer 

30 la vue I2_V2 . La mSthode meth2 cr6e done une instance 
de la classe F_I2_V2 k partir du paramdtre regu et 
retoume par 1 ' instruction return la r6f Srence a 
I'objet filtre cr66 en retour de la m§thode meth2* 
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La m^thode meth3 ne retransmet pas I'appel 
puisqu'il n'est pas autoris6, et propage done une 
exception. 

5 L* implantation lorsque les applications 

coop^rantes Aa et Ab sont toutes les deux dans la 
carte a puce respecte les principes decrits ci- 
dessus. Par centre, lorsqu'une des deux applications 
se trouve hors de la carte, 1 • implantation est 

10 sensiblement diff^rente. 

II est rappele que les appels de methodes entre 
une station d'accueil SA, telle qu'un terminal, et 
une carte S puce CP comme montre schematiquement a la 
figure 6 sont implantes a partir de messages, appeles 

15 unites de donnees de protocole applicatif APDU, entre 
la station d»accueil SA et la carte a puce CP, ces 
appels de methode n'^tant effectues que suivant le 
sens de la station d'accueil vers la carte. En effet, 
la station d'accueil et la carte a puce, ou en 

20 variante deux cartes a puce ou deux controleurs dans 
une carte a puce ou un terminal, comprennent des 
microcontroleurs constituant des moyens de traitement 
de donnees qui sont respectivement maitre et esclave 
et qui dialoguent selon un protocole d'fichange de 

25 donnees asynchrone qui oblige la station d'accueil & 
interroger pSriodiquement la carte pour que celle-ci 
declenche en reponse une action dans la station 
d'accueil . 

En variante, la station d'accueil dans la suite 
30 est remplac^e par une autre carte a puce, c'est-S- 
dire les applications coop^rantes Aa et Ab sont 
implantSes respectivement dans deux cartes a puce, ou 
plus g6n6ralement dans deux controleurs. 

Le protocole d*§change de donnees asynchrones 
35 implique que, pour un appel relatif S un objet Obi 
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depuis 1 'application Aa dans la station d'accueil SA 
vers 1 'application Ab dans la carte CP ^ laquelle 
appartient I'objet Obi, lorsqu'il y a retransmission 
d'un appel entre deux objets filtres Fa (Obi) et 
Fb(Obl), relatifs a I'objet Obi, cette retransmission 
de 1' appel prenne la forme d'un echange de message 
entre la station d'accueil et la carte. Une station 
d'accueil d'origine inconnue (pirate) est alors 
capable d'etablir un message correspondant a un appel 
de methode bien qu'elle ne soit pas reellement 
autoris§e a realiser cet appel de methode. Ceci 
revient a creer une capacite ce qui n'est pas 
possible dans le schema de protection selon 
1 ' invention. 

Pour proteger les capacit4s centre ces attaques, 
des secrets, tels que mots de passe mdp, 
eventuelleraent basSs sur des mSthodes de chiffrement, 
sont utilises. 

Comme montre a la figure 6, lorsqu'a une 
premiere 6tape E3 1 ' application Aa dans la station 
d'accueil SA appelle la methode meth2 sur un objet 
Obi appartenant a 1' autre application Ab dans la 
carte CP, c'est-^-dire lors de I'accds a 1 'objet Obi, 
et lorsqu'S une deuxieme Stape E4 le rSsultat de cet 
appel de methode retourne une capacity d'acc^s sur un 
objet Ob2 appartenant a 1 'application Ab, le filtre 
Fb(Obl) cr6e le filtre Fb(0b2) dans le systdrae 
d' exploitation de la carte CP pour cette capacite 
d'accds. Selon 1' invention, le filtre Fb(Obl) ggndre 
alors un secret, tel qu'un mot de passe mdp qui est 
stocke dans le filtre Fb(0b2) et retourng au filtre 
Fa (Obi) qui le stocke egalement. Ainsi, lorsque le 
filtre Fa (Obi) cr€e le filtre Fa(0b2) dans la station 
d'accueil SA pour la capacite d'accds retourn^e, le 
filtre Fa (Obi) passe au filtre Fa(0b2) le mot de 
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passe mdp qui y est stocke. En d'autres termes, 
I'accds g I'objet Ob2 est protege dans les 
applications Aa at Ab respectivement par deux 
capacit^s ajoutees illustrees par les filtres Fa(0b2) 
5 et Fb (Ob2 ) . 

Lorsqu'a I'gtape E4 cette capacit§ retoum^e en 
paramdtre est utilisSe pour appeler une mSthode sur 
I'objet Ob2, I'appel entre les filtres Fa(0b2) et 
Fb(Ob2) inclut le mot de passe dans le message APDU, 
10 ce qui permet au filtre Fb(0b2) de verifier que la 
capacity d'accds a I'objet Ob2 est valide. 

invention cr€e ainsi par nommage une 
correspondance entre un objet et une capacity 
illustrge par un filtre, geres par les systemes 
15 d' exploitation dans les moyens de traiteraent de 
donnges, tels que station d'accueil et carte S puce. 
Si un objet est supprimg dans une application, le 
systdme d' exploitation respectif d^truit le filtre 
correspondant . 

20 

Ainsi, la cooperation entre une application Ab 
dans la carte avec une application quelconque 
necessite de gerer des capacit^s pouvant prendre deux 
formats, avec mot de passe si 1 ' application 

25 quelconque est exportee hors de la carte et sans mot 
de passe si elle reste dans la carte. 

Le schema de protection ci-dessus utilise des 
r^f^rences, sortes de pointeurs, a des objets JAVA 
qui sont presque des capacites. En effet, ^tant donne 

30 que le langage JAVA est sflr, il n'est pas possible 
dans un programme JAVA d'etablir une reference a un 
objet et d* appeler une m^thode sur cet objet. Ceci 
implique que si un objet 01 cree un objet 02, 1» objet 
02 n*est pas accessible a partir des autres objets de 

35 1 'environnement JAVA, tant que 1* objet 01 ne transmet 
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pas ejqplicitement i I'objet 02 vine rgfSrence a ces 
autres objets. Cette transmission de rgf^rence ne 
peut se faire que par passage de paramdtre lorsqu'un 
objet appelle I'objet 01 ou lorsque I'objet 01 
5 appelle un autre objet. 
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REVENDICATIONS 

1 - Procede de controle d'acces entre deux 
applications (Aa, Ab) cooperant chacune au moyen de 

5 capacites sur des objets appartenant a 1' autre 
application, les applications cooperant a travers au 
moins un syst§me d' exploitation et §tant implant^ 
dans un moyen de traitement de donnSes (CP) , 
caract^rise par I'itape suivante : 

10 lorsqu'a I'une (Aa) des applications, dite 

application demandeur d'accgs, est donnS un accds IL 
un objet (Ob ; Obi) appartenant 3 1' autre application 
(Ab) , dite application fournisseur d'acces ; 

creer (EO) deux capacites (Fa(Ob), Fb(Ob) ; 

15 Fa (Obi), Fb(Obl)) respect ivement dans lesdites 
applications demandeur et fournisseur d'accds, en 
tant qu' objets ; 

la capacity cr66e dans 1 ' application fournisseur 
d'acces (Ab) pour limiter I'acces audit objet (Ob) 

20 et ; 

la capacite cr§§e dans 1 ' application demandeur 
d'acces (Aa) pour associer 1 ' application demandeur 
d'acces a la capacite creee dans 1/ application 
fournisseur d'acces (Ab) . 

25 

2 - Proc6de conforme k la revendication 1, 
conprenant lors de l»accds (El; E3) k un objet (Ob ; 
Obi) appartenant a I'une (Ab) des applications, si un 
deuxidme objet (Oa ; Ob2) appartenant k I'une (Aa ; 

30 Ab) des applications est pass6 ^ cette application, 
I'gtape d'aj outer (E2, E4) deux autres capacites 
( Fa (Oa ) , Fb (Oa ) ; Fa ( Ob2 ) , Fb ( Ob2 ) ) respect ivement 
dans les applications (Aa, Ab) pour prot^ger I'accds 
au deuxiSme objet. 

35 

3 - Procfidi conforme k la revendication 2, selon 
lequel la capacity d'acc§s au deuxi^me objet (Oa ; 
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Ob2) appartenant h l*une des applications est passSe 
en parametre ou en r^sultat ^ 1' autre application. 

4 - Precede conforme a I'une quelconque des 
5 revendi cat ions 1 k 3, caract§ris6 par 1 ' exportation 

d'une capacity depuis line application (Ab) vers 
!• autre application (Aa) en I'associant Sl un nom 
symbolique, et 1 ' importation de la capacity d'accSs 
exportge dans 1' autre application en interrogeant un 
10 serveur de nom avec le nom symbolique. 

5 - Precede conforme a I'une quelconque des 
revendi cat ions 1 a 4, selon lequel les applications 
(Aa, Ab) sont implantees dans un moyen de traitement 

15 de donnees commun (CP) . 

6 - Proc^d§ conforme a I'une quelconque des 
revendications 1 a 4, selon lequel les applications 
(Aa, Ab) sont implantees respect ivement dans deux 

20 moyens de traitement de donnees distants (SA, CP) 
gchangeant des messages d'accds a des objets 
distants . 

7 - ProcSde conforme a la revendication 6 
25 lorsqu'elle depend de la revendication 2 ou 3, selon 

lequel l»etape d'ajouter deux autres capacitSs (E4) 
comprend le stockage d'un mot secret (mdp) dans les 
deux autres capacitSs (Fa(0b2), Fb(0b2)) pas8§ a 
celles-ci par les deux capacit§s (Fa (Obi), Fb(Obl)) 
30 prScedemment creees . 

8 - Proc^dg conforme k la revendication 6 ou 7, 
selon lequel les moyens de traitement de donnSes sont 
inclus respect ivement dans une carte S puce (CP) ^t 

35 une station d'accueil (SA) de la carte Sl puce. 
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9 - ProcSdg conforme S la revendication 6 ou 7, 
selon lequel les moyens de traitement de donnSes sont 
inclus respect ivement dans deux cartes k puce. 

5 

10 - Precede de gin^ration d' applications 
caracteris6 en ce qu'il coirprend : 

- une 6tape de developper une application (Ab) 
cotnprenant un objet (Ob) ou plusieurs objets (Ob, 

10 Obi), sans restriction d'acces ; 

- une etape de dSfinir des regies de droits 
d'acces k 1' objet (Ob) ou axix objets (Ob, Obi) 
compris au sein de 1 ' application depuis une seconde 
application (Aa) ou depuis plusieurs autres 

15 applications ; 

- une Stape de transformer 1' application (Ab) 
comprenant le ou les objets (Ob, Obi) par ajout i 
ladite application (Ab) , de moyens de f iltrage (Fa, 
Fb) des acc^s audit objet (Ob) ou auxdits objets (Ob, 

20 Obi) pour mettre en oeuvre le procedg de contr61e 
d'acces selon les revendi cat ions 1^4; 

- une etape d'implanter 1 ' application 
transformee au sein d'un moyen de traitement de 
donnees (CP, SA) . 

25 

11 - ProcedS conforme i la revendication 10 selon 
lequel le moyen de traitement de donnees est inclus 
dans une carte a puce. 

30 12 - ProcSdg conforme a la revendication 10 selon 

lequel le moyen de traitement de donnees est inclus 
dans une station d'accueil (SA) de la carte a puce. 
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